aete Resources
Volume Number: 11
Issue Number: 7
Column Tag: Applescript
Making Sense of ‘aete’ Resources 
The inside scoop on building an application’s scripting dictionary.
By Gary McGath, Hooksett, NH
An important step in making an application support Apple Events and scripting is the
creation of an ‘aete’ (Apple Event Terminology extension) resource. This resource
defines the Apple Events and objects which your application understands, both for
scripts and for applications that send you events. Unfortunately, the documentation for
this resource is widely scattered; also, it has many “magical” features which are
explained only in tech notes and journal articles, and probably others which are
unknown outside Apple. This article tries to bring together the most important pieces
of information so that the reader can put together an ‘aete’ resource with a minimum
of confusion and understand some of its subtleties.
To keep this article from digressing too far, I’m assuming you have a general
familiarity with Apple Events. The background you need can be found in Inside
Macintosh: Interapplication Communication, chapters 3 through 6. If you’ve never
worked with Apple Events, you should learn the basics before there’s any point in
trying to create ‘aete’ resources.
Any application that responds to more than the basic four Apple Events, and any
scripting addition, should have an ‘aete’ resource. It should have only one of them, and
its ID must be the same as the language code specified in the resource. If the target
language is English, this means its ID must be 0.
An ‘aete’ resource is organized as a hierarchy of information. It consists of one
or more suites, each of which describes a distinct collection of Apple Event
information. The hierarchy looks like this:
Suites
Suites are basic to the logical organization of Apple Events. If you’ve worked at all
with Apple Events, at minimum you’ve run into the Required Suite and the Core Suite.
The Required Suite consists of the four basic events which every application should
support (Open Document, Open Application, Print, and Quit). The Core Suite describes
a basic set of events which scriptable applications are expected to support. Other
commonly used suites are the Text, Table, and Database suites, which respectively
provide classes to describe text, two-dimensional arrays of data, and databases
(including complex tables). You should try to work within Apple’s standard suites,
defining your own only if they prove insufficient.
A suite consists of events, classes, comparison operators, and enumerations.
Events and classes are the most important parts of a suite; events tell the world what
your application can do, and classes tell what it can do it to.
Enumerations are an adjunct to events and classes; they are a form of data
definition in which a parameter or property can take on one of several named values
(e.g., “Yes,” “No,” and “Cancel”).
Comparison operators usually defined in ‘aete’ resources when a new data type is
defined. In addition, the ‘aete’ resource is identical to the ‘aeut’ resource, which
defines the scripting dialect and needs this capability. For everyday purposes, you’ll
probably not define one, and they aren’t discussed in this article.
Looking at the ‘aeut’ resource can be useful for studying existing suites. This
resource is found in the AppleScript dialect files, in the System
Referenced by (1):